Vercel Previews Deployed

Hey @schavis this PR looks good- however just a question about the implications this change this would have. From my research pull_request_target event (the current implementation) runs in the base repo context (with access to secrets) so it works for internal PRs but also for PRs from forked repos. Was this intentional behavior? The new change, on the other hand, works the same for internal PRs but with no secrets for forked PRs, so any automation requiring secrets will not work for PRs from forks. I'm all for the new change since it has added safety, but just wondering if there was a specific reason to use pull_request_target in the first place that I don't want to overlook

@williamdalessandro tbh it was just about safety. We would still like contributor PRs to be properly labeled. Is there an alternative permission that makes sense (narrow scope without skilling fork-based PRs)? I'm not aware of one.

@williamdalessandro tbh it was just about safety. We would still like contributor PRs to be properly labeled. Is there an alternative permission that makes sense (narrow scope without skilling fork-based PRs)? I'm not aware of one.

@schavis is

on:
  pull_request_target:
    types: [opened, synchronize, reopened]

not valid?

@schavis is {snip} not valid?

I thought I tried that and it didn't work, but let me double check. I had a lot going on at the time 🙃

@williamdalessandro Testing worked in my fork. Let me know if it's still okay to merge :)